The present invention relates to a tool operable within an integrated development environment for client-server object oriented applications and a method for dividing application software into archive files for decoding prior to execution on a client.
Client machines connected to the Internet run Web browsers which generally operate by establishing a TCP/IP connection with a server web site and downloading files written in hyper-text mark-up language (HTML) from the web site. Java enabled browsers running on conventional type personal computers include a Java Virtual Machine (JVM) in which Java byte-code is executed within the browser. More recently, however, dedicated Java Machines, such as Palmtop computers have become available, and the present invention is beneficial in both environments. In any case Java enabled browsers are responsive to xe2x80x9cappletxe2x80x9d tags within HTML files to allocate an area of a desktop display within which an applet can operate, and to download the necessary class files required to execute the applet. The class files to be downloaded depend on the objects instantiated during applet program execution. A menu based program will usually cause a number of menu objects to be instantiated and so menu class files need to be downloaded. Similarly, graphics type applets will require graphic classes. It is acknowledged that class files may be cached on a client machine prior to applet execution, but the benefits of caching to class download time are not of concern in relation to the present disclosure and in any case are in addition to the benefits provided by the present invention.
There are three ways to run an applet within a browser environment. They all center around the applet tag and how the browser is to continue when it sees one. The simplest method simply holds a reference to the first class that is to be called:
 less than applet code=COM.ibm.test.TestApplet.class width=280 height=30xe2x80x3 greater than 
This is essentially a reference to the xe2x80x9cmainxe2x80x9d method of the TestApplet class. When Java wishes to run the applet it goes back to the server and requests the TestApplet class. As the class is loaded into the JVM, the JVM parses the class and looks at the referenced classes within the class, that is, the classes required when new objects are instantiated, for example, xe2x80x9cObject1=new Class1xe2x80x9d. The JVM then spawns off separate threads to load these classes from the server and repeats the process until no more classes are required.
Each thread loads its classes using the hyper-text transfer protocol (HTTP) to communicate with the server. HTTP is primarily a stateless protocol and is a relatively slow way to download information as it requires a TCP/IP connection to be set-up between client and server for each request/response couple in a transaction. Also, the downloaded classes which comprise Java byte-code are not compressed and so this adds to the inefficiency of the protocol for transferring this type of information.
The second method of loading a set of classes tries to overcome these problems by putting all of the necessary files into an archive file. For Java the file is referred to as a xe2x80x98jarxe2x80x99 file and archiving classes is referred to as xe2x80x98jarringxe2x80x99. A similar Microsoft system is available where the necessary files are put into xe2x80x9cCABxe2x80x9d, cabinet files. For Java, however, the tag looks something like this:
 less than applet code=COM.ibm.test.TestApplet.class archive=TestAppletArchive.jar width=280 height=30xe2x80x3 greater than 
The concept here is that the JVM sees the applet tag and sees that the class is held within the archive file. Therefore it attempts to load the jar file. From that point onwards the applet has (if the jar file has been correctly made) all of the necessary files that it requires to execute so no more loading is required.
The third potential way that class files can be introduced into the JVM is via a number of jar files where the application has been divided manually by a developer. The tag looks something like this:
 less than applet code=COM.ibm.test.TestApplet.class archive=TestAppletArchive.jar,TestAppletSecondJar.jar width=280 height=30xe2x80x3 greater than 
The JVM runs as before but when the JVM runs out of classes, during the execution of classes from the first jar, the JVM goes off and loads the second jar file to see if the required classes are in there and so on if other files are listed. If none contain the required class, then the program fails.
Presently, creating and loading jar files relies to a great extent on what is within the jar file. This is obviously fine so long as the jar file doesn""t get too large and therefore take a great deal of time to download before the application can start working. With the coming of larger and larger applications which are being placed in jar files, there has come the problem that applications are having larger and larger lead in times. This is generally unacceptable to the vast majority of users who want local application response times even in an Internet environment.
It is not beneficial, however, to simply divide source code from top to bottom into blocks and to archive classes required for these individual blocks because this does not take into account the order in which classes are required at run-time.
Integrated development environments (IDE) are available to enable developers to visually build applications, in particular Internet applications. Examples are, IBM VisualAge from International Business Machines Corporation or Java Bean Machine from Lotus Corporation for Java based applications or Microsoft Visual Studio for developing, ActiveX applications in particular. IDE""s like IBM VisualAge provide an export facility allowing a developer to xe2x80x98jarxe2x80x99 or in the Microsoft case xe2x80x98cabxe2x80x99 an application once it has been written. Another common feature of IDE""s is that once a developer has authored an application, it is possible to run the application within the IDE. IDEs to one extent or another also allow developers to debug programs by tracing program execution in some cases, such as IBM VisualAge, at a source code level.
In a first aspect, the present invention makes use of IDE tracing techniques to monitor the execution sequence of an application in particular to determine when objects are instantiated from given classes for the first time.
Thus, the present invention provides a tool operable within an IDE for client-server object oriented applications, said tool comprising: means for analysing a running application to trace the first instantiation of classes within the application; means for grouping classes according to when they are first instantiated into respective groups; and means for archiving said groups into respective archive files capable of being decoded prior to execution of said application on a client.
The present invention overcomes the problems of the prior art by looking at more than just what files are needed in an archive file and addressing the problem of what files are needed and in which archive file. The invention enables an application developer, for example, to give the user a logon screen or a small piece of the application immediately whilst downloading the rest of the application from another archive file in the background. This fulfils the requirement of the user to have immediate availability of something to do with an Internet application as well as minimizing the amount of code downloaded and so saving on network bandwidth.
In a preferred embodiment, the tool adapts the developer""s application source code to include class file pre-loading code, so that archive files including classes to be required later in program execution are downloaded beforehand to further reduce application response time.